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ABSTRACT 


This  thesis  examines  tie  questiDis  of  user  requirements, 
design  considerations,  aid  network  environment  for  a  local 
area  network  Terminal  Management  function  in  sipport  of  the 
Naval  Supply  Systems  Command's  S^dck  Point  Logistics 
Integrated  Communications  Environment  (SPLICE).  Criteria 
are  developed  from  this  examination.  They  include  process- 
process  communication,  virtual  terminal,  and  user  defined 
screen  capabilities  as  well  as  a  negotiated  virtual  terminal 
protocol  based  upon  a  network  virtual  terminal  concept. 
Recommended  generic  and  specific  nsaels  of  the  Terminal 
Management  function  applying  these  criteria.  are  then 
presented. 
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I.  IiiTRODOCTIDW 

A-   OBJECTIVES  OF  RESE&RCa 

The  objective  of  the  Stock  Poiat  Logistics  Integrated 
Conmunica tions  Environment  (SPLICEl  Loral  Area  Setwork  (LAN) 
Project  at  the  Naval  Postgraduate  School,  Monterey,  was  to 
develop  alternatives  for  SPLICE  LANs.  The  thesis  submittal" 
by  Lieutenant  Joesph  N.  Rslnhart  III,  USMC  aid  Lieutenant 
Ricardo  Arar.a,  Peruvian  Navy  [Ref.  1  ]f  concerns!  itself  with 
ths  development  of  functional  dssigi  specifications  for  the 
implementation  of  the  Database  and  Terminal  Management  func- 
tions of  a  functionally  listributed  LAN  in  response  to  the 
requirements  of  the  -Naval  Supply  System's  stccc  points  and 
inventory  control  points. 

The  objectives  of  this  thesis  research  is  to  further 
define  the  requirements  of  the  SPLISE  users  and  to  develop 
from  these  needs  a  generic  model  of  Terminal  Management  (TM) 
functions  necessary  to  sapport  tae  services  reg.uired.  The 
rationale  for  using  a  geasric  aodsl  rather  than  a  specific 
model  lies  in  the  evolutionary  state  of  Naval  Supply  Systems 
Conmar.d  (NAVSUP)  data  processing  objectives.  In  an  execu- 
tive level  briefing,  the  SPLICE  project  office  stated  : 

We  cannot  afford  the  luxirv  of  supporting  "Navy  unique" 
software  packages  (in.  the  future*.  We  sifloxy  cannot 
afford  the  resource  dra*  (drain) .  Our  policy  oust  not 
allow  unique  solutions.  Our  systens  mus-  fit  within  the 
technology  and  capabilities  of  tis  general  .\D?  market- 
place,  [fief-  2] 

In  keeping  with  that  policy,  this  thesis  will  attempt  to 
recommend,  using  the  Reinhart  and  krana  thesis  as  a  theoret- 
ical foundation,  a  TM  functional  specification  capable  of 
supporting  presently   envisioned  SPLICE   LAN  configurations, 


while   presenting  the  capability   ta   supper-   svolutionary 
cca figurations  of  the  future. 


B.   BACKGROUND 

SPLICE,   as   concieved  by   NAV3U?  iascribes   a  aear-tera 

system  to  provide  badly  needed  local  and  system  aetworfc 
coinunication  and  management  functioas  without  further  ever- 
loading  the  present  .host  system,  it  also  presents  the 
conceptual  foundation  for  cespones  to  future  changes  :o  both 
customer  requirements  ar.l  technological  advances.  SIIICE 
draws  together  under  one  conceptual  umbrella  the  myriai  of 
new  applications  being  developed  independently  throughout 
the  supply  shore  establishment. 

SPLICE,  in  its  simplest  form,  is  designed!  to  provide  a 
hardware  and  software  aroaitectura  capable  of  supporting  a 
wine  variety  of  interactive  application  programs  on  both 
local  and  remote  terminals.  Hhen  filly  realized  this  capa- 
bility will  significantly  reduce  tea  proliferation  of  stan3 
alone  computers  at  support  sites  presently  unable  no  obtain 
da- a  processing  services  otherwise. 

Significant  factors  which  will  latermine  tie  siccess  of 
tha  SPLICE  concept  will  be  the  spesd  and  accuracy  of  data 
and  file  transfers  within  and  betwse?.  LANs  and  the  speei, 
accuracy  and  ease  of  interactive  terminal  sessions.  It  is 
the  latter  concern  which  is  tha  reason  for  this  thesis. 

NA7SU?  and  Fleet  Material  Support  Dffice  SPLICE  documen- 
tation provide  detailed  information  en  SPLICE  software 
design  considerations  [Ref.  3],  systems  so  serf icat ions 
[Raf.  4],  functional  dssigi  [Raf.  5],  and  teleco  aaunciations 
plans  [Ref-  6].  References  7  and  3  provide  insight  into  the 
magnitude  and  variety  of  transactions  containai  in  typicial 
applications  which  SPLICE  rfili  be  expected  to  support.  Us 
tha   LAN   design    project,    with   which   this    thesis   is 


associa-ed,  is  not  constrained  by  SPLICE  designs  and 
specifications,  the  above  references  were  usei  primarily  as 
a  source  of  purpose  and  oojectives.  Reference  1  provides  a 
very  readable  synopsis  of  References  3  through  5  .  Readers 
desiring  such  information  ire  referral  to  sectians  IA  and  13 
of  that  document.  In  keeping  with  the  objective  of  their 
research,  Reinhart  and  Araaa  presented  their  recommendations 
for  Database  and  Terminal.  Management  functional  specifica- 
tions in  support  of  a  LAS.  In  :a=  name  cf  brevity,  a 
lengthy  condensation  of  that  thesis  will  not.  as  provide-:  in 
this  thesis.  Instead,  as  this  thssis  uses  the  Beinhart  end 
Arana  thesis  as  a  jumpiag-cff  point,  later  developments 
ana/or  information  that  night  modify  that  thasis  will  be 
presented  in  section  C  of  this  introduction. 

Additional  insights  into  the  variety  and  size  of  the 
tasks  expected  to  be  processed  on  ths  SPLICE  LAS  were  gained 
by  personal  contacts  with  persons  attached  to  the  SPLICE 
prajecn  office  at  NAVSJP  headquarters  in  Washington,  D.C. 
and  functional  managers  at  Naval  Supply  Centers  in  Oakland 
ana  San  Diego.  The  intent  of  this  thesis,  and  therefore 
these  interviews,  was  to  establish  in  the  author's  mind  a 
generic  definition  of  interactive  processing  requirements  so 
that  Terminal  Management  (TM)  alternatives  might  ds  evalu- 
ated. The  results  of  these  investigative  interviews  are 
contained  in  Chapter  II  of  this  thesis. 

C.   ADDENDUM  TO  REINHART  AND  ARAN!  T3ESIS 

In  their  background  section,  Jsinhart  ana  Arana  impiiei 
that  a  commericai  proiuct  named  Terminal  Application 
Processing  System  (TAPS)  was  the  most  probabla  implementa- 
tion of  terminal  managenent,  iatabase  management,  complex 
management,  and  transport  management  functions.  At  the 
tine,   that   was  a   valid  assumption   and  share!   by  NAVS9P. 
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Actual  responses  have  shown  that  a  significant  number  of 
vendors  responiir.g  the  th  =  SPLICE  s:>  licitation  prefer  their 
owa  functional  modules  to  TAPS  and  irs  bidding  accoriir.gly. 
This  action  would  appear  to  suppor:  Reir.hart  and  Arana,s 
contention  that  a  f unotiDnally  distributed  LAN  without  a 
central  complex  manager  is  viaDle. 

Section  ID  of  the  tresis  discisses  SPLICE  functional 
implementation  and  provides  a  iiagraa  in  its  Figure  1.3  of  a 
possible  implementation.  An  updated  version  of  that  diagram 
is  contained  in  Reference  9  and  Figure  1.1  below. 


Operating  Functions 
Implemented   in   Software   Modules. 


Support 
Function. 
■  IXrpl.e.ntea' 
in   software 
|     oodulM) 


(Memory  Module)         (tenory  Module) 


[Ref.  9:  p. 4-6] 


Figure  1.  1    Possible  Logical  LAN  Connections, 
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Also  discussed  in  sastion  ID  3f  Reference  1  are  the 
relative  merits  of  a  high  level  database  qusry  language 
versus  the  interactive  application  programs  approach  of 
NAVSUP.  The  thesis  implies  that  N^VSU?  should,  and  there- 
fore has  yet  to,  investigate  the  feasibility  of  a  dataoass 
query  language  capability  within  SPLIC2.  This  author's 
interviews  and  a  review  oE  NA73UP  policy  guidance  indicate 
than  NAVSQP  has  the  evsntial  development  and  uss  of  such  a 
qusry   language    high    on    thsir    ADP    p-i^riny    list. 
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II.  REQOIREMENrS  DEFINITION 


OVERVIEW 


The  method  employed  in  attempting  to  arrive  at  a 
requirements  definition  for  the  rsrminal  Management  (IM) 
function  was  a  series  of  interviews  using  standard  ques- 
tions. The  interviews  rfere  conducted  with  persons  at  the 
Naval  Supply  Centers  at  Oakland  and  San  Diego.  These 
centers  were  chosen  primirily  because  of  locale,  but  this 
choice  does  not  diminish  the  effectiveness  of  the  inter- 
views. Between  them,  Sai  Diego  aid  Oakland,  conduct  the 
entire  range  of  stock  point  operations,  with  the  exception 
of  strategic  forces  support.  San  Diego  supports  a  major 
fleet  presence,  a  large  training  command,  two  major  air 
stations,  and  numerous  siDre  iiaint  enance  and  administrative 
commands.  Oakland  supports  a  smaller  fleet  presence,  one 
air  station,  fewer  shore  establish^ en ts,  but  serves  as  a 
clearing  house  for  Western  Pacific  requirements.  Both 
centers  presently  support  remote  terminal  operations.  3oth 
have  implemented  either  or  both  IDA  or/and  APADS  to  varying 
degrees.  These  terminal  based  interactive  application 
programs  are  currently  executed  on.  stand-alone  minicompu- 
ters, but  their  mere  existence  allows  the  functional 
managers  using  them  to  answer  questions  not  answerable  by 
managers  without  experience  with  this  type  of  approach. 

The  impressions  ganered  fron  these  interviews  are 
contained  in  section  B  below.  Section  C  discusses  informa- 
tion gained  in  meetings  with  NAVSUP  SPLICE  project  office 
personnel.  Section  D  sunnarizes  the  user  requirements  and 
associated  assumptions  that  will  ae  used  throughout  the 
remainder  of  this  thesis  in  evaluating  TM  approaches. 
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B.   STOCK  POINT  BEQOIREHEHr S 

Interviews  with  stork  point  functional  managers  quickly 
established  the  presence  of  manageriil  difficulties  expects^ 
in  -crying  to  hold  together  m  ongoing  production  effort 
based  on  established  procedures  and  technology  while  trying 
to  simultaneously  implement  a  newer  technology.  Despite 
their  tribulations,  these  managers  were  most  willing  to 
share  their  experiences  to  date  with  terminal  based  interac- 
tive application  programs. 

Both  IDA  and  APADE  are  designed  to  utilize  a  menu-driven 
form  mode  of  interactive  lata  entry  and  file  inquiry/update. 
Both  have  extensive  process  options  available  10  the 
terminal  user. 

The  APADE  users,  primarily  in  the  purchasing  division  of 
the  Procurement  Department,  logicalLy  and  physically  sepa- 
rate data  entry  functions  from  data  inquiry/update 
functions.  This  is  base!  mostly  upon  time  constraints  of 
data  entry  and  the  volume  of  these  transactions.  The  TM 
implications  of  this  separation  is  that  the  data  entry 
clerks  would  be  best  served  by  the  Least  creative,  least 
complicated  TM  that  would  still  sipport  interactive  form 
data  entry,  i.e.,  when  finished  with  one  form,  the  user 
wants  another  form  immediately,  nor  a  helpful  out  neverthe- 
less key-stroke  consuming  menu.  Di  the  other  hand  their 
co-wcrkers  who  are  responsible  for  handling  a  rather  large 
number  of  document  inquiries  fr^m  not  always  patient 
customers  would  find  the  ability  to  split  their  screen  into 
multiple  sections  and  to  conduct  a  separate  inquiry  or 
update  in  each  section  very  helpful.  The  purcaasing  admin- 
istrative personnel  are  frequently  asked  to  produce 
information  (written  and  ocal)  that  requires  multiple  access 
to  files  ani/or  manual  manipulation  of  the  data  accessed. 
The   primarv   ca use   of   their    effort   is   that   thev   are 
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constrained   by   the   fornats,   both   display   and   reports, 

designed  into  the  system.  The  capability  to  design  a 
multiple-use  screen  and  report  fornat  at  tha  terminal  is 
indicated. 

The  IDA  users,  financial  accounting,  comnor.ly  referred 
to  as  Triple-A,  do  not  separata  their  data  antry  from 
inquiry/update.  Each  dark  who  has  a  terminal  has  often 
foind  himself  in  the  situation  of  naading  to  view  a  record 
from  more  than  one  file.  Pais  situation  is  especially  preva- 
lent when  reconciling  vendor  invoioes  with  requisitions. 
This  need  is  presently  net  by  calling  a  clerk  who  has  access 
to  the  necessary  files  (\PADE  or  U&3PS)  and  passing  the 
necessary  information  by  alone  --  automation  indeed! 

The  Customer  Services  personnel  primarily  interface  with 
the  UADPS  applications  residing  on  :he  Burroughs  host  main- 
frame. Their  interaction  with  the  :oa?uter  is  varied,  twit 
basically  inquiry  in  natura.  Data  antry  is  normally  batch 
processed,  and  will  in  ail  likelihood  remain  so  until  0Z3. 
technology  replaces  the  current  card  readers.  Because  most 
queries  are  made  to  records  store!  and  processed  in  30 
column  card  format,  a  scroll-mode  terminal  presentation  with 
the  ability  to  continually  enter  queries  and  direct  replies 
to  a  nearby  printer  is  the  near  concensus  choice  for 
terminal  interaction.  k  less  frequent  activity  conducted  by 
Customer  Servicas  personnel  requiras  them  to  spend  hours 
researching  and  cross  referencing  records  from  various  UADPS 
and  financial  files  (now  IDA  files) .  This  reasearch  is 
normally  conducted  by  the  nost  experienced  and  senior  clerks 
and  supervisors  in  the  division,  so  it  would  seem  that 
countless  hours  could  be  saved,  not  to  mention  dollars,  if 
these  persons  could  break  away  from  the  standard  displays  to 
which  they  are  now  limited  and  sat  up  a  screen  display 
suitable  for  researching  and  controlling  tna  source  of 
display  input. 
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In  warehousing  and  ■  at 2 rial   receipt  functions,   the  use 

of  automation  has  just  bagur,  primarily  in  stowage  art 
retrieval  operations,  rha  day  of  tia  use  of  bar  codes  and 
light  pens  for  receipt  processing  ani  inventory  sir.i:ejrr.: 
is  still  soiawhit  distant.  Although  "-are  is  good  reason  to 
suspect  that  these  devices  should  b  =  considered  nerioherals 
and  therefore  nor  within  the  purview  of  this  mesis,  the 
author  car.  envision  a  scenario  vhera  they  would  be  direct 
input  devices  to  several  UADP5  application  programs.  Is 
such,  the  author  has  chosen  to  incline  them  in  the  category 
of  potential  terminals. 

C.   NAVSO?  POLICY  AHD  DIRSZTIOB 

In  addition  to  a  survey  of  stork,  point  personnel,  a  trip 
was  mane  to   Washington,  D.C.      ::  last   with  SPLICE  project 

office  personnel.  The  objective  of  tha  meetings  was  to  gain 
an  appreciation  for  the  lirection  of  SPLICE  LAN's.  Although 
the  development  of  a  generic  TH  model  from  re  guir  emer.t  needs 
is  deemed  academically  justifiable,  there  remained  the 
concern  that  to  stray  too  far  froi  the  realities  of  the 
Naval  Supply  System  would  result  In  an  academic  exercise  of 
little  intern.  The  guotation  cited  In  Chapter  I,  Objectives 
of  Research  sertion,  convinced  t  h  r  s  i  u  t  h  c  r  that  such  a  model 
could  in  fact  be  of  use,  particularly  in  view  :f  the  desirs 
to  meve  away  from  "Navy  uaique"  software.  The  functional  1'A 
■odel  presented  in  Chapter  17  represents  the  author's  tesnre 
to  produce  a  recommendation  for  tha  near  future,  and  there- 
fore embraces  the  reality  of  the  5PLICI  environment  more 
than  the  generic  TH  model  press rtei  in  Chapter  III. 

Additional  information  gained  fr:~  these  meetings 
included  familiarization  with  the  long-term  objectives  nf 
SPLICI  implementation.  Although  tiese  objectives  do  not  fit 
tha  category  of  user  rsguir emen ts ,  tdey  ars  paraphased  zelcv 
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because    failure      to    keep      them   in   mini      in   a      issigr.    p::c5s  = 
increases   the   probability   that   the      resultant   design   may   too 
restrictive  to   be  of   value    in  meeting    future   growth. 
HMSDP   SPLICE  Project   Ibjeotivss 

Data  must  be  made  available  t  o  the  customer,  easily 
accessed  from  wherever  tie  customer  is  located  on  a  conti- 
nuous  basis    around   the  clock. 

A    distributed    data   base   must    be    developed. 
Goals    for    NA  VSUP    ADP 

All   punched   cards    aust   be    slininated. 

The  use  cf  point-of-sale  terminals  and  hand  held 
terminals  with  optical  scanning  capabilities  at  data  entry 
points. 

The  use  of  bar  codes  and  magnetic  strips  in  inventory 
control    and   warehousing   applications. 

D.       CONCLUSIONS     AND    ASSUMPTIONS 

The  following  conclusions  regarding  the  TM  requirements 
of  users  of  the  SPLICE  LAN  are  based  upon  the  interviews 
discussed  above  and  observations  of  terminal  use  at  stock 
points.  Assumptions  are  based  uooi  the  same  observations 
coupled  with  the  author's  experience  in  stock  point 
operations. 

1.  A  TH  must  be  able  to  support  a  wide  variety  of  termi- 
nals, varied  not  only  in  aake/modelr  but  also  in  operational 
characteristics . 

2.  A  TM  must  be  able  to  sjpport  character,  line,  page, 
scroll,  and  form  mode  editing  npabilites  at  the  same 
terminal. 

3.  A  TM  should  provide  the  ability  for  a  user  to  locally 
format  a    display   area,    and    resultant    hardcopy    output. 
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4.  A  user  should  be  abis  to  simultaneously  display 
multiple    processes    utilizing    diffscsit    application    programs. 

5.  A  TM  should  provide  the  mechanism  to  allow  applica- 
tion   to   application    interaction    (author's  assumption ) 

6.  A  TM  should  be  able  to  suppDrt  non-interactive  data 
entry,  such  as  light  pens  and  hini-held  D3R  (author's 
assumption)  . 

7.  A  TM  should  provide  a  general  framework  within  which 
future  terminal  functions  can  be  accomodated  (author' = 
assumption)  . 

8.  A  TM  design  must  recognize  the  relative  lack  of 
sophistication  cf  potential  jsers  and  the  probability  of 
high   turnover   in   these   positions. 
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III.  ASPECTS  DP  TERMINAL  MANAGEMENT 

A.  OVERVIEW 

In  addition  to  the  user  requirements  liscussed  in 
Chapter  II,  investigation  and  evaliation  of  alternative  TM 
techniques  requires  an  appreciation  for  the  technical 
concerns  of  a  TM.  Section  B  discusses  these  concerns. 
Section  C  outlines  the  LAN  environment  assuaed  for  -his 
thesis.  Section  D  presents  the  author's  view  of  a  generic  TM 
model.  Section  E  then  explores  soae  of  the  TM  approaches 
cited  in  contemporary  literature.  Section  F  contains  a 
review  of  the  TM  approach  advocate!  by  Reinhart  and  Arana 
[Ref.  1]. 

B.  TM  TECHNICAL  CONCERNS 

TM,  as  a  list  of  wiiely  agreed  to  discrete  functions  and 
protocols,  does  not  exist.  Rather,  there  exists  an  impres- 
sive, if  somewhat  confusing,  spectrin  of  alternative  methods 
of  implementing  a  TM.  Dn  the  most  ambitious  end  of  this 
spectrum  is  a  TM  module  tfhich  provides  the  full  range  of 
functions  described  in  the  Presentation  Layer  (layer  6)  of 
the  International  Standaris  Organization  (ISO)  Open  Systems 
Interconnection  (OSI)  reference  noisl.  One  of  the  many 
definitions  of  the  task  of  the  Presentation  Layer  "...is  to 
support  communications  by  providing  commonly  known  virtual 
devices  and  commonly  known  virtuil  information  to  th= 
distributed  applications"  [Ref.  10:  ?.  227].  A  less  ambi- 
tious TM  would  be  expected  only  to  "hiie  terminal 
idiosyncracies  from  the  application  programs"  *Sef.  11:  p. 
U8U ].   The  latter  representing  a  subset  of  the  former. 
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It  is  helpful  to  try  ta  describe  the  iesign  concerns  of 
a  r it  and  then  to  blend  these  concerns  with  user  requirements 
tc  fori  a  model  of  the  ideal  or  jeneric  TH  which  would 
recognize    both    the    desigrsr's   =  r.f    jest's    concerts. 

A  suggested  list  of  concerns  cf  the  IB  ceslcr.er  is 
found    in    Reference    12    (??.     82-84)-      rhese   concerns    are: 

1)  Control  of  th_e  le-ninal  Handling  -  Assuming  the  wide 
variety  cf  terminals  and  ittendant  /arietv  cf  characteris- 
tics, the  parameters  which  affect  local  handling  cf  a 
terminal  must  be  known  to  the  PH,  an3  to  no  other  LAS  rciile 
nor    tc   remote   users. 

2)  Dialogue  ^cde  -  Fiie  m  she  i  Li  prc7iie  wet  hods  for 
selecting/providing  supper-  for  both  half-duplex  or  full- 
duplex   operations. 

3)  Terminal  lata  Stricture  -  Lika  terminal  ccr. trol  char- 
acteristics, the  TH  ajs:  be  avara  of  the  lata  structure 
parameters   cf   the     terminal    as    well    i=      the   couiand   language 


-  1  si 


primitives    avaniao.e    for    ■ampliation    or 


acture. 


4)  ~Y.~~.strv      -    The    easier    cf      tha    Tw.    rust      be    concert ei 
with    the      desirability   if      symmetrical    fcrms      cf    connection, 

e.g.    prccess-pr o cess    ati    terminal-ter ilnal    interactions 

5)  ^i§i21=i.l=2=£     "      The      TM      aust      proviia      a      lynamic 
mechanism    tc    negotiate     res    facilitias    and    paraiiaters      tc    re 

6)  Al_..=Ll=2i~   "    The    E3    aust    be    capable    cf    Lnterpretting 
and    hand  line      the  varierv    if      methods    user    in      ta: 


~  ~       c:      •= 


processes   tc    signal    "rraa<", 


ni -  f  II  Itahl  —  " 


tier,    cc  mm  an  as.       Tnese  sigr.  -iS   are    normally    expeiiteo    sigra_s 
"cut-cf-bani"    ::    outside    tie    normal    flew    of    daia. 
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C.       LOCAL    AREA    NETWORK    (LAS)     ENVIRONMENT 

The  LAN  environment  ii  which  ths  TM  being  discussed  in 
this  thesis  will  operate  is  a  fully  distributed  LAN  based 
upon  seven  primary  functional  s0ftw2.ce  modules;  local  commu- 
nications, national  con maa icat ions,  front-end  processing, 
session  services,  terminal  management,  database  management, 
and  peripheral  management.  Figure  1.1  introduced  the  logical 
connections  of  this  LAN.  Figure  3. 1  presents  a  possible 
physical    connection      configuration. 
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Figure   3. 1         Possible    Physical    LAN    Connections. 
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This  thesis  also  assunes  a  multiplexed  data/control  bus 
capable  of  supporting  half  and  full-duplex  coamunications. 
Further,  it  is  assumed  that  the  terminals  connected  or 
potentially  connectable  to  this  LAM  are  hetrogeneous  and 
that  the  hetrogenous  mix  »L11  be  in  2.  constant  state  of  flux 
during  the  next  decade. 

D.   GENERIC  TM  MODEL 

Given  the  user  r equirea ents,  design  concerns,  and  envi- 
ronmental assumptions  developed  above,  Figure  3.2  presents 
the  author1 s  attempt  to  meet  these  criteria  with  a  generis 
TM  model. 
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Figure  3.2    Generic  Terminal  Management  Hodel. 
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Figure  3.2  has  the  following  components: 

1)  A  generic  terainal  with  an  input  capability 
(keyboard,  light  pen,  optical  scanner,  etc.)  ani  an  optional 
output  device  (CRT  screen,  signal  light,  teletype,  ate). 

2)  A  device  or  module  which  cai  understand  the  signals 
coming  from  the  input  device  and  can  send  signals  to  the 
output  device  which  it  cai  recognize.  This  component  also 
has  a  command  language  of  its  own  which  allows  the  user  to 
design  an  output  display  aid  to  map  ncre  than  one  process  to 
that  display. 

3)  This  component  represents  the  terminal  in  dealings 
with  the  application  process  (one  per  process),  It  also 
builds  and  manipulates  a  terminal  lata  structure  for  each 
process. 

4)  This  component  represents  the  application  program  in 
dealings  with  the  terminal  process  (one  per  process).  It 
also  builds  and  manipulates  an  application  data  structure 
for  each  process. 

5)  This  component  sets  the  rules  for  and  format  of 
communications  between  the  terminal  processes  and  applica- 
tion processes  (for  all  processes). 

In  the  most  simplistic  terms  components  3  and  4  are 
attorneys  for  their  clients,  the  terminal  and  the  applica- 
tion program,  respectively.  They,  ani  only  the/,  know  their 
clients  capabilities  ani  ex  pectations.  Both  are  very  strong 
willed  and  therefore  neei  an  arbitrator  (component  5)  to 
ensure  that  communicatins  are  meaningful  and  properly 
coordinated. 

At  this  point  this  model  simply  provides  an  ideal  TH 
whose  generic  components,  if  implemented  ideally,  wouli 
provide  a  modular  TM  capable  of  meeting  user  requirements 
and  design  concerns  while  having  the  flexibility  to  respond 
to  changes.  A  recommendei  specific  implementation  of  this 
model  will  be  presented  in  Chapter  17. 
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E.       TERMINAL    HANAGEMENT    APPROACHES 

Approaches  to  TM  can  be  generally  discussed  in  two 
broad,  and  unfortunately  iDt  mutually  exclusive,  categories; 
parametric   and  virtual  terminal. 

1  •      Parametr  ic    A£Dna:ies 

Generally,  parametric  teniaal  protocols  attempt  to 
list  a  set  of  terminal  charac  teristics  with  each  type  of 
terminal  having  a  different  set  of  parameters  for  eacn  char- 
acteristic. The  host  computer  may  then  set  taa  parameters 
available  on  that  terminal  to  values  needed  for  the 
process/application    [Ref.    12:    pp.    34-86]. 

This  approach  is  used  by  the  ARPANET  Telenet 
protocol  and  by  systems  imple nenting  International 
Consultative  Committee  foe  Telephones  and  Telegraphs  (CCITT) 
recommendations . 

When  evaluating  these  two  approaches  the  ARPANET 
Terminal  Interface  Processor  (TIP)  is  compared  to  the  CCirr 
Packet  Assembler/Disassembler  (PAD).  Beth  approaches  use  a 
primitive  command  language  to  open  aid  close  connections  ancl 
to  set  terminal  parameters.  The  primary  difference  being 
the  perceived  role  each  plays  in  the  network  architecture. 
In  the  ARPANET  the  TIP  is  a  limited  capability  logical  host 
with  knowledge  of  terminal  parameters.  Whereas,  the  CCITT 
considers  a  PAD  an  integral  part  of  :he  network  acting  as  an 
interface  between  data  terminating  equipment  (DTE).  A  DTE 
can  be  either  a  host  or  a  terminal  [Ref.  12:  pp.  84-86], 
[Ref.    13:    pp.    335-348],    [Raf.    14:    pp.     586-587], 

The  PAD  cited  in  33  ITT  protocols  is  the  most  compre- 
hensively defined  parametric  apprcaci  to  terminal  handling. 
There  are  three  basic  approved  reco mmendatioas  covering 
operation  of  the  PAD;  X. 3  rfhich  defines  the  PAD  itself,  X.23 
defines    the   interface  between   the    teriinal   and    cne    PAD,       anl 
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X.29   defines  the   interface  between   the  PAD   and  the   host 
[Ref.  12:  pp.  84-86]. 

The  shortcoming  of  these  approaches  is  that  the  PAD 
protocols  provide  no  generic  functisas-  They  assume  that 
the  application  in  the  host  knows  what  the  teriinal  will  do 
and  that  the  terminal  will  do  what  is  intended  [ Hef .  14: 
pp.  586-587]. 

Telenet1  s  Interactive  Terminal  Interface  (III) 
provides  an  enhanced  set  Df  parameters  which  helps  offload 
some  of  the  terminal  handling  responsibilities  from  the 
host.  Telenet  offers  a  farther  refinement  called  a  virtual 
terminal  which  includes  a  few  generic  functions  on  top  of 
the  ITI  parameters.  Unfortunately,  the  ARPANET  virtual 
terminal  was  designed  primarily  zo  support  scroll-type 
terminals  which  have  inch  fewer  parameters  than  more 
sophisticated  page  and  form  mode  terminals.  Although  the 
list  of  parameters  was  extended,  few  of  the  options  (parame- 
tric values)  were  implemented  [fief.  1<4:  pp.  586-587]. 

Both  these  approaches  are  most  suitable  for 
providing  TM  for  existing  terminals,  the  more  hDmogenity  the 
better.  To  be  really  useful,  these  functions  should  be 
standardized  so  that  the  host  system  can  rely  upon  a 
PAD/interf ace  with  known  properties.  Even  with  standariza- 
tion  the  envolvement  of  -hi  host  system  in  TM  would  still  be 
extensive  or  the  list  of  ? AD/interf ace  parameters  would  be 
enormous  [Ref.  13:  pp.  347-348]. 

As  several  of  the  user  requirements  and  design 
concerns  discussed  earlier  imply  the  need  for  the  greatest 
amount  of  transparency  ichievable  and  further  imply  an 
increasing  number  and  variety  of  terminals,  the  parametric 
approaches  appear  too  limited. 
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2-   Virtual.  Terminal  Protocols 

Virtual  Terminal  Protocols  (VTP)  have  undergone 
significant  evolution  since  the  first  VT?  was  placed  in  use 
by  the  ARPANET.  This  7TP  was  designed  primarily  with 
scroll-mode  terminals  in  mind.  It  is  based  upon  three  basic 
principles;  the  concept  of  a  'network  virtual  terminal1,  the 
concept  of  negotiation  of  options,  and  a  symmetrical  view  of 
terminals  and  processes  [8af.  12:  p.  38]  [  Ref .  "U:  p.  588]. 
This  first  VT?  laid  very  firm  ground  for  further  sophistica- 
tion of  the  Virtual  Temiial  (71)  .  Jnfortunat ely ,  although 
the  Telenet  VIP  was  designed  with  fifty-eight  parameters, 
very  few  were  actually  implemented.  It  therefore  remains  to 
explore  a  few  more  of  the  many  VTP  approaches  developed 
since  the  ARPANET  VTP. 

A  model  which  focuses  on  page  and  fcra  mode  termi- 
nals was  developed  by  Schicker  and  Ouenki.  It  is  used  in  the 
European  Informatics  Netork  (EIS)  and  is  described  in 
Reference  15  (p.  '485).  This  model  is  called  a  data  struc- 
ture model.  In  it  a  data  structure  is  viewed  as  containing 
a  set  of  fields  each  of  which  has  cer.ain  attributes  such  as 
size  of  the  field,  what  type  of  characters  it  contains, 
whether  cr  not  the  field  can  be  modified  by  the  user,  etc. 
This  definition  of  a  data  structure  has  become  widely 
accepted  and  will  be  used  in  the  renainder  cf  this  thesis. 
This  model  assumes  that  application  programs  are  written  tc 
perform  abstract  operations  on  a  data  structure  and  that  the 
reaote  (user)  process  has  a  siaiiar  data  structure.  The  VI? 
is  the  mechanism  by  which  the  changes  made  by  the  applica- 
tion process  to  its  data  structure  are  passed  to  the  user 
process  so  that  its  data  structure  can  be  changed  accord- 
ingly, and  vice  versa. 
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A  refinement  of  the  data  structure  model  is 
described  in  Reference  13  (pp.  362-355).  la  this  model  a 
terminal  has  a  data  structure  and  a  controlling  process 
called  a  "T-PAD"  with  a  relationship  much  like  that 
described  in  the  parametria  approach  in  subsection  1  of  this 
section.  Similarly,  the  host  system  has  a  data  structure 
with  which  it  is  designs!  to  interact  via  a  controlling 
process  called  an  "S-PAD" .  The  messages  passed  between 
these  two  "PADs"  to  negotiate  the  data  structure  and  the 
available  commands  to  minipulats  the  data  structure  are 
contained  in  the  VTP.  Tie  appeal  of  this  approach  is  two- 
fold; the  S-PAD  implies  a  NVT  concept  such  as  described  by 
Tanenbaum  in  Reference  15  (p.  423)  ,  where  a  NVT  is  an 
abstract  terminal  the  characteristics  of  which  are  assumed 
by  all  interactive  application  prognms;  secondly,  a  symme- 
trical approach  such  as  tiis  allows  not  only  the  traditional 
terminal  to  application  interaction,  but  also  terminal  to 
terminal  and  application  to  application  interaction,  given  a 
sufficiently  adept  VTP.  The  utility  of  such  capabilities 
can  be  shown  in  a  common  Stock  Point  scenario.  This  scen- 
ario exists  when  an  application  program,  such  as  APADE, 
creates  records  that  are  duplicated  or  entered  into  files 
necessary  to  the  correct  operation  of  another  application 
program,  such  as  IDA.  For  instance,  the  establishaent  of  a 
contract,  which  reguires  a  record  ipdate  in  an  APADE  file, 
also  necessitates  an  update  of  a  financial  record  in  an  IDA 
file.  Such  changes  can  be  made  by  batch  processing  (current 
practice)  or  by  application  to  application  interaction  such 
as  made  possible  by  a  TM  La plementin g   this  type  of  model. 

The  approach  above  is  very  similar  in  function,  if 
not  vocabulary,  to  the  NVT  envisioned  for  ARPANET'S  Telenet 
protocol  and  the  INWG  VIP.  All  ace  deemed  symmetrical  in 
that  each  side  of  a  session  has  its  own  view  of  the  state  of 
the   VT   [Ref.  14:    p.    5  89].     rais   as   opposed   to   an 
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asymmetrical  model  where  the  VI  is  considered  Drily  from  the 
perspective  of  the  application  progran.  In  sucn  a  model  the 
physical  terminal  is  transformed  by  software  to  appear  as  a 
VT  to  the  application  program  [Ref.  16:  p.  304],  This 
approach  cannot  support  terminal  to  terminal  or  process  to 
process  interaction  [fief.  14:  p.  588]. 

In  each  of  the  vr  concepts  described  the  VT's  are 
supported  by  two  elementary  protocols;  a  virtual  terminal 
display  data  transformation  protocol  and  a  control  protocol. 
The  data  transformation  protocol  maps  display  commands  from 
the  sending  process  into  the  prescribed  input  daxa  formats 
foe  the  receiving  process.  The  roatrol  process  exchanges 
non-display  information  for  coordinating  interactions 
[Ref.  17:  p.  85]. 

A  more  expansive  approach  is  offered  in  Reference 
10.  In  this  approach  three  abstractions  (vir~ uaiiza~ions) 
are  proposed;  a  virtual  device,  a  conceptual  data  ~ype 
definticn,  and  a  conceptual  image.  The  virtual  device  is 
considered  an  association  between  a  definition  of  a  struc- 
ture for  a  (device)  data  object  and  a  set  of  operations 
which  are  the  o rly  means  for  accessing  this  (device)  data 
object.  The  conceptual  data  type  definition  is  a  similar 
association,  but  with  regard  to  the  structure  of  data  and 
the  operations  which  nay  be  peformed  on  data  structure 
objects.  The  conceptual  image  is  considered  a  definition  of 
the  means  by  which  a  mapping  of  the  conceptual  data  or.  the 
virtual  device  is  obtained.  The  thrust  of  this  concept  is 
that  in  a  hetrogenous  network,  assi npt ions  regarding  inden- 
tical  virtual  devices  and  data  structures  may  net  be 
desireabie  and  possibly  not  practically  viable.  Only  an 
agreement  of  negotiated  parameters  need  be  known  by  each 
partner.  The  authors  wrote  a  follow-on  article,  [Ref.  18], 
in  which  they  presented  a  detailed  recommendation  of  the 
protocols  and  options  for  each  of  these  visualizations. 
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All  of  the  above  approaches  require  the  negotiations 
of  options/parameters  to  be  used  In  a  session,  be  they 
device  characteristics,  data  structure  d:  commands. 
Negotiations  are  either  asynchronous  or  master-slave  (synch- 
ronous) depending  on  the  symmetry  of  the  interaction  and  tha 
trust  the  designers  place  in  whateirar  mechanism  they  may 
have  implemented  to  resolve  negotiation  deadlocks.  The 
literature  regarding  negotiation  algorithms  seems  polarized 
with  each  side  singing  tha  praises  :)  f  their  approach.  The 
author's  preference  is  included  in  the  TM  model  presented  in 
Chapter  IV. 

F.   REINHART  AND  ARANA  TM 

In  Reference  1  (p.  5  5),  the  ajthors  proposed  a  TS 
approach  based  upon  a  "Virtual  Terminal"  manageasnt  concept. 
The  primary  feature  of  their  VI  is  that  it  "...  converts  a 
single  physical  terminal  into  multiple  virtual  terminals, 
each  of  which  may  be  written  into  or  queried  for  input".  To 
support  this  concept  the  idea  o£  a  user  defined  screen 
configuration  is  proposed.  This  *ould  allow  a  user  to 
divide  his  screen  into  "windows"  earn  of  which  contains  the 
display  of  a  separate  procass.  although  only  one  window/ 
process  would  be  active  at  a  given  moment,  it  is  clear  that 
tha  implementation  of  this  concept  *ould  satisfy  several  of 
the  requirements  and  concerns  addressed  earlier  in  this 
thesis. 

The  thesis  also  discuss  on  page  74  the  use  of  a  generic 
terminal  transformation  taole.  This  table,  as  proposed  by 
Hillsberg  [Ref.  19]  is  ised  to  convert  specific  physical 
terminal  sub- functions  to  generic  commands  and  vice  versa. 

Although  this  thesis  :)*es  its  r^ots  to  the  Reinhart  and 
Arana  effort,  subsequent  readings  and  investigation  have  led 
this   author  to   step   back   from   nost   of   the   specifics 
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presented   in    their   thesis   and      mova    toward    a   broader   concept 
foe    TM   functional     specification   usiig    their   coaoepts      as    an 

inspiration. 
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IV.    BECQMMENDAriDNS 

A.  OVERVIEW 

The  recommendations  contained  in  this  chapter  are  a 
marriage  of  the  generic  VA  model  presented  and  the  variety 
of  specific  approaches  discussed  in  Chapter  III.  The  resul. 
is  a  specific  model  consisting  of  exponents  and  protocols 
interfacing  those  components.  General  recommendations  are 
listed  in  section  B  below.  Section  2  presents  the  recom- 
mended model. 

B.  GENERAL    RECOMMENDATIONS 

1)  The  TM  should  be  based  upoi  the  concept  of  a  NVT. 
Each  application  program  should  be  aole  to  assume  that  it  is 
dealing  with  a  terminal  wnere  the  default  parameters  will  be 
used  unless  the  user  negotiates  different  parameters  using 
the  NVT  capability. 

2)  The  TM  should  support  the  highest  level  of  abstrac- 
tion technologically  available. 

3)  Negotiation  of  device  definitions  should  be  hierarch- 
ical.    Standard  classes   of   terminals  defining   mandatory 
characteristics  (minimum  parameter  values)   should  reside  at 
the  highest  levels  of  the  hierarchy.  Optional  (negotiatible) 
operations  should  reside  at  lower  le/els. 

H)  The  TM  should  support  user  defined  screen  format  for 
use  in  both  displaying  multiple  processes  and  designing 
display  and  possible  report  format. 
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C.       RECOMMENDED  TM    MODEL. 

Figure      4.1  presents      the      Terminal      Management      !lodel. 

recommended      by  the      author.      The      components   3-2      explained 
below. 
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Figure    4.1        Recommeniei    TM    Model. 


1  .      Inp_ut^Ou tput    Device 

A  terminal  is  viewed  as  two  separate  devices.  The 
separation  recognizes  that  a  LAN  may  recieve  input  from 
devices  that  have  no  outpit  capability,  e.g.  light  pens,  OCR 
scanners,  etc.  The  rn  mast  be  able  to  handle  inputs  fro:t 
suoh  devices.  Additionally,  the  ability  to  transform  and 
control  inputs  is  conceived  to  be  totally  separated  from  the 
ability  to  control  and  map  output. 
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2.  Local   Tirtaal  Terminal    (LVT) 

The  function  of  the  L7 T  is  to   hide  the  idiosychra- 

cies  of  the  user   terminal  from  the  LAN  and  to   nap  its  data 
structure  and  any  changes  to   that  structure  to  the  terminal 
display  device.   The  LVT  consists  of  a  terminal  process  (T?) 
component  and  a  disk-based  terminal  lata  structure  (TDS). 

The  TP  utilizes  a  generic  terminal  transformation 
table  (see  Ref  19)  to  virtualize  terminal  sub-functions  and 
a  hierarchically  organized  set  of  terminal  primitives  and 
parameters  as  discussed  in  paragraph  B.3  above.  The  TP  also 
US2S  a  user  defined  map  of  the  screei  display  for  output. 

The  TP  is  responsible  for  representing  the  terminal 
in  negotiations  with  the  application  process  (or  another 
TP)  .  It  is  also  responsible  for  napping  terminal  input 
commands  to  the  TDS  and  for  mapping  TDS  changes  to  the 
output  unit.  These  functions  are  conparabie  to  the  "T-PAD" 
discussed  in  Reference  13  and  Chapter  III. 

3.  Network  Virtual  Terminal  (NVT) 

The  NVT  is  configured  identically  to  the  LVT  with  an 
application  process  (AP)  in  place  of  the  TP.  Ine  AP  has  the 
same  data  structure  modifications  re sponsibilir ies,  except 
that  it  takes  orders  from  and  reports  changes  to  an  applica- 
tion program  as  opposed  to  a  terminal.. 

The  major  conceptual  difference  between  the  NVT  and 
the  LVT  is  that  the  NVT  is  a  parametric  model  of  the  entire 
network's  concept  of  a  teriinal.  Its  primitives  and  parame- 
ters are  fixed.  The  application  program's  requirements  are 
met  by  passing  necessary  parameter  /alues  to  the  AF.  Note 
that  the  number  of  parameters  are  fixed,  but  that  each 
parameter  may  offer  more  than  one  option  (value).  The  A? 
then  represents  the  application  program  in  negotiations  with 
the  T?  as  to  what  values   will  actuaLly  be  used.   Obviously, 
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the  AP  will  not  agree  to  any  parametric  values  lower  than 
the  program  requires,  bat  it  may  agree  to  higher  values 
should  the  TP  insist.  The  AP  hides  all  negotiatisd  values 
from  the  program  except  those  that  tie  program  expects. 

4.  Virtual    Terminal   Protocol    (VTP) 

The  VTP  is  a  message  based  protocol  with  several 
functions,  discussed  here  in  chronological  order.  The  VIP 
controls  the  the  exchange  cf  negotiation  messages  between 
the  TP  and  AP.  During  these  negotiations  the  primitives  and 
parameter  values  of  control  messages  are  selected  as  well  as 
the  contents  of  the  data  structure.  The  recommended  negoti- 
ation protocol  will  be  explained  in  the  session  example 
below.  Cnce  all  values  aire  set,  the  VTP  becomes  responsible 
for  passing  control  messages  between  the  TP  and  AP  for  the 
manipulation  of  their  respective  lata  structures.  In 
fulfilling  this  responsibility,  the  VTP  controls  the 
sequencing  of  messages  according  to  the  communication  method 
selected  during  negotiations,  i.e.,  alternating  or  free- 
running,  and  dictates  the  format  of  these  messages. 

5 .  Session    Example 

a)  The  user  logs  on  his  terminal  identifying  himself 
and  the  terminal  ID.  Terminal  ID  can  be  done  automatically 
if  the  capability  exists. 

b)  The  TP  will  compute  the  command  signals  needed  to 
handle  this  particular  terminal  using  the  transformation 
table.  The  TP  will  then  begin  a  screen  formatting  subroutine 
conversation  with  the  user,  in  which  the  first  user  response 
may  result  in  a  default  screen.  (note:  asking  the  question 
rather  than  waiting  for  the  user  to  request  screen  format- 
ting should  evoke  curiosity  and  quieten  the  learning  process 
for  this  feature)  This  routine  will  construct  the  output  map 
for  the  TP's  subsequent  interaction  «rith  the  output  devi< 


.ce. 
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c)  Once  the  as?r  has  defined  the  scree?.  format 
desired,  the  first  (and  possibly  only)  command  to  call  an 
application   program    is   entered. 

d)  The  TP  passes  this  message  to  the  LAN  which  may 
need   to    send  it    out    to   the    long-haul    network. 

e)  The  destination  node  will  establish  an  AP  to 
which  the  application  program  passes  its  terminal  and  data 
structure  requirements.  kt  this  point,  and  throughout  the 
negotiation  process,  tie  VIP  is  ensuring  one-way 
con  munications. 

f)  Once  negotiatioi s  have  bean  completed,  the  appli- 
cation program  directs  the  A?  to  sat  the  initial  state  of 
its  data  structure.  Qpoi  doing  so,  the  AP,  using  the  VTP 
message  format,  passes  the  agree!  lata  structure  instruc- 
tions to  the  TP  which  both  creates  an  identical  initial 
state  in  its  data  structure  and  maps  the  data  structure  to 
the    user-defined   screen    forma-. 

g)  At  this  point  the  VTP  nay  allow  free-running 
(asychronous)  communications  if  both  parties  can  support 
such. 

h)  When  the  application  program  is  completed,  the 
connection  is  severed  and  the  TP  begins  its  user  dialouge 
anew. 

Admittedly,  this  TM  model  is  a  compromise  between 
the  generic  goals  presented  in  Chapter  III  and  the  practical 
implications  of  NAVSUP's  dedication  to  application  programs. 
A  acre  esthetically  plsasiig  concept  is  outlined  in  Chapter 
V. 
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V.    THE    REZ3MMENDED    APPROACH 

A.  THE    ASSUMPTIONS 

The  concept  discussed  in  this  chapter  is  a  recommenda- 
tion for  the  future.  It  is  based  or.  tha  following 
assumptions : 

1)  NAVSUP  is  willing  to  abandon  the  development  and  use 
of  application  programs  in  favor  of  functional  modules  and  a 
distributed  database  systen . 

2)  NAVSUP  defines  the  set  of  queries  and  reports  it 
wishes  the  system  to  provide. 

3)  NAVSUP  is  willing  to  allow  increased  local  flexi- 
bility in  the  design  of  display  and  report  formats. 

B.  THE  CONCEPT 

Given  the  above  assuno tions,  the  envisioned  data  base 
system  would  be  built  by  use  of  a  data  base  "designer"  and 
program  generator  such  as  discussed  in  Reference  23  .  The 
basic  tool  of  this  building  process  is  called  a  Hierarchical 
Interactive  Query  (HI-IQI  language.  The  result  of  this 
process  would  be  a  database  capable  of  supporting  programs 
written  in  a  COBOL  Data  Manipulation  Language  (DHL)  for  data 
entry  and  inquiry.  The  primary  charn  of  this  concept  is  tha 
reduction  of  redundant  rscord  fields  in  different  applica- 
tion files  and  the  concomitant  reduction  in  required  file 
space.  Given  that  there  are  only  tm  primary  fields  forming 
the  backbone  of  the  vast  majority  of  stock  point  and  inven- 
tory control  point  transactions,  the  requisition  number 
(order  number)  and  the  National  Stock  Number  (or  part 
number) ,  the  concept  of  a  hierarchical  data  base  system  to 
support  what  is  now  supported  by  "JADPS  file  management 
programs  is  not  so  far-fetched. 
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A  second  enhancement  this  approach  offers  is  the  elimi- 
nation of  the  need  for  application  to  application 
interaction,  be  it  batch  or  interactive.  Because  the  finan- 
cial data  field  for  a  JADPS  requisition  entry  is  the  same 
field  used  in  IDA,  the  need  for  passing  this  information  to 
ths  IDA  application  progran  for  entry  is  eliminated. 

C.   TH  IMPLICATIONS 

Adoption  of  the  systen  described  above  would  not  neces- 
sitate scraping  the  TM  rarommendei  In  Chapter  IV,  but  to 
fully  capitalize  on  the  benefits  of  the  system,  certain 
changes  would  be  necessary. 

The  most  important  change  would  be  to  enhance  the 
Terminal  Process  (IP)  by  providing  it  with  a  data  structure 
description  language  whin  would  logically  be  a  subset  of 
the  system's  Data  Han ip illation  Language  (DML)  .  This 
language  would  be  available  to  a  user  tc  name  fields  and 
zones  and  for  defining  tie  attribites  and  dimensions  of 
such.  This  capability  would  enabls  users  to  easily  design 
screen  and  report  formats  tailored  to  their  needs.  But,  such 
a  capability  would  requirs  a  rethinking  of  tha  application 
program's  master  role  in  establishing  data  structure 
parameters. 

As  this  concept  would  move  away  from  the  application 
emphasis  on  form  or  page  assigns  in  lata  structures,  changes 
would  also  be  necessary  in  NVT  ani  VTP  paraneters.  3oth 
could  be  simplified  because  they  would  not  have  to  be  struc- 
tured to  support  a  myriai  of  often  conflicting  application 
pro  grams. 

Should  the  assumptions  in  sectioi  A  evolve  ,  the  concept 
outlined  in  this  chapter  is  strongly  rscommendrd  for  further 
study. 
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